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Abstract 

Recent work on relationship-based access control has begun to show how it can be applied 
to general computing systems, as opposed to simply being employed for social networking 
applications. The use of relationships to determine authorization policies enables more 
powerful policies to be defined than those based solely on the commonly used concept of 
role membership. 

The relationships, paths and principal matching (RPPM) model described here is a 
formal access control model using relationships and a two-stage request evaluation process. 
We make use of path conditions, which are similar to regular expressions, to define policies. 
We then employ non-deterministic finite automata to determine which policies are applicable 
to a request. 

The power and robustness of the RPPM model allows us to include contextual informa¬ 
tion in the authorization process (through the inclusion of logical entities) and allows us to 
support desirable policy foundations such as separation of duty and Chinese Wall. Addi¬ 
tionally, the RPPM model naturally supports a caching mechanism which has significant 
impact on request evaluation performance. 


1 Introduction 

In modern computing there are very few computer systems where every user of that system is 
required to be able to perform all possible actions on all possible resources. More usually there 
is a need to selectively limit the actions which can be performed on resources; access control 
is the security service which provides this capability. The reasons why such limitations are 
required vary depending on the computer system. There may simply be a distinction between 
configuration (administrative) functions versus operation (user) functions, or between a write 
mode and a read mode. There may be a need to isolate the data belonging to each individual 
user from every other user, or there may be more complex requirements based on concepts such 
as security clearance level, job role or previous activity. 

In many situations, access control is policy-based: interactions between users and resources 
are modeled as “requests” and the policy specifies (either implicitly or explicitly) which requests 
are to be granted and which denied. An access control system is based on an access control 
model, which will define the data structures used to specify an authorization policy and an 
algorithm, often known as a policy decision point, to determine whether a request is authorized 
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by a given policy. As is customary in the literature we will use the terms subjects and objects 
when referring to the parties who are to, respectively, perform and be the target of authorization 
(inter)actions. 

There have been numerous access control models defined since the topic first attracted interest 
in the mid-1960s. The protection matrix model simply enumerated all authorized actions 1321 . 
This is a conceptually simple approach, however, it is inefficient when dealing with more than 
a few subjects and objects. New models have been introduced with the intention of addressing 
limitations in existing models or to accommodate richer types of authorization policy. 

A prime example of this is the Role-Based Access Control (RBAC) model which allows per¬ 
missions to perform actions to be granted to job roles. Subjects are assigned to their applicable 
roles and thus gain the permissions to perform the necessary actions for that role. The RBAC 
model offers several significant benefits over previous models. In particular, it reduces the admin¬ 
istrative burden of managing the access control system by abstracting policy assignment away 
from subjects to roles; additionally, it is conceptually simple, thereby being easily understood 
and implemented. It is principally for these reasons that it (or some close variant) has become so 
widely utilised in modern computing systems. Since RBAC’s inception there have been numer¬ 
ous variations and extensions suggested to adapt it for specific applications. These extensions 
have included, for example, support for role hierarchies, as well as geographical and temporal 
constraints mm- 

More recently, alternative models have been growing in popularity, with Attribute-Based Ac¬ 
cess Control (ABAC) [3] and Usage Control (UCON) [33] receiving particular attention. All 
these models assume that authorization should, essentially, be based on user attributes (partic¬ 
ularly user identities). However, in many computing systems, it is not the individual that is 
relevant to the access control decision, but the relationship that exists between the individual 
requesting access and the resource to which access is requested. Consider, for example, a request 
by a user u to read the records of a patient p. The fact that u is a doctor is a necessary, but 
not sufficient, condition for access to be granted. Specifically, u should be one of p’s doctors. A 
second example arises when the same user may occupy different roles in different contexts. A 
PhD student, for example, may be an enroled student on course c\ and a teaching assistant for 
course C 2 . Clearly, a request to read the coursework of another student should be disallowed if 
the coursework is for course c\ and allowed if for course C 2 . Whilst parameterized variants of 
RBAC are able to bundle the context into the role [31] , this often leads to a proliferation of roles 
as each specific context must be ‘identified’. As the number of roles tends towards the number of 
users this undermines RBAC’s reduced administrative burden. Access control languages based 
on first order logic or logic programming can express complex access control policies that can 
deal with such situations 13 ESI- However, this comes at the cost of complexity, both for end 
users that have to specify policies and in terms of policy evaluation. 

A new paradigm, known as relationship-based access control, has emerged, particularly to 
address access control in online social networks mm- In this paper, we extend relationship- 
based access control to arbitrary computing systems. We provide a richer policy framework than 
RBAC, taking relationships into account, while retaining conceptual simplicity. However, we 
also exploit features of RBAC and Unix to provide a scalable and intuitive policy language and 
evaluation strategy. We introduce the concept of a path condition , which is used to associate a 
request with a set of security principals at request time. The security principals are authorized 
to perform particular actions. Thus, at a high-level a security principal is analogous to a role. 

The RPPM model takes its inspiration from the Unix access control model, RBAC and exist¬ 
ing work on relationship-based access control. However, it provides a much richer and more flexi¬ 
ble basis for specifying access control policies than any of these models. In particular, it provides 
arbitrary flexibility in the definition of principals, unlike Unix; it supports policy specification 
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based on relationships, unlike RBAC; and it provides policy abstraction (based on principals) 
and support for general-purpose computing systems, unlike existing work on relationship-based 
access control (which has focused on social networks). At the heart of the RPPM model is 
the system graph and the set of relationships. In this paper, we describe how relationships are 
used to define principal-matching policies and how requests are interpreted in the context of the 
system graph and principal-matching policies. We demonstrate how a policy decision point can 
be constructed, based on non-deterministic finite automata (NFA). We also describe how the 
RPPM model can easily support more advanced access control concepts, which greatly increase 
the performance and flexibility of the model, thereby broadening its suitability for practical 
implementations. 

In the next section, we formally define the core RPPM model and the authorization policy 
structures. Section [3] describes how NFAs are used to evaluate requests within the model. Sec¬ 
tion U details a set of extensions to the basic model, by introducing the notion of typed edges. 
We provide a discussion of related work in Section [5] and draw conclusions in Section [G] 

2 The Model 

The central component of the RPPM model is the system graph, a labelled graph in which nodes 
represent the entities of the system being modelled and the labelled edges represent relationships 
between them. As well as concrete entities, such as users and resources, nodes can also represent 
logical entities with which other entities are associated. These logical entities can be employed 
to give context, or some system-specific grounding, to the concrete entities. For example, in 
the case of a medical records management system we may have concrete entities representing 
patients, doctors, healthcare records and medicines; additionally we may have logical entities 
representing medical cases, healthcare teams and research projects. 

A labelled edge linking two nodes identifies a relationship between these nodes. Such edges 
may be directed (asymmetric) or undirected (symmetric) depending on the type of relationship. 
Paths of edges in the system graph are used to match path conditions which identify principals to 
be associated with an authorization request. It is these principals which are assigned permissions 
to perform actions on objects. 

2.1 System Model and System Graph 

The RPPM model is designed as a general model for access control, utilising relationship infor¬ 
mation in order to make authorization decisions. This generality comes from the model’s ability 
to support whatever entity and relationship types are necessary to describe a particular system 
at the desired level of detail (unlike Unix, say). Whilst such flexibility is powerful, it can also 
limit the checks and controls available for administration of an implementation of the model. 
In order to provide an underlying structure and, therefore, a basis on which to incorporate the 
appropriate checks and controls, we first define a system model which constrains the “shape” of 
the system graph. 

Definition 1. A system model comprises a set of types T, a set of relationship labels R, a set of 
symmetric relationship labels SCR and a permissible relationship graph Gpp = (Vpr, Epr), 
where Vpp = T and Epp C T x T x R. 

Definition 2. Given a system model (T, R, S,Gpp), a system instance is defined by a system 
graph G = (V) E), where V is the set of entities and E C V x V x R, and a function r : V —> T 
which maps an entity to a type. We say G is well-formed if for each entity v in V, t(v) £ T, 
and for every edge (v,v',r) £ E, {t(v), t(v'), r) £ Epp. 
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Our definition of a system graph allows for multiple edges between nodes, as multiple rela¬ 
tionships frequently exist between entities in the real world; such a graph is sometimes called 
a multigraph. The administrative interface for any implementation of the RPPM model must 
ensure that the system graph is always well-formed with respect to its underlying system model. 
As the system being modelled may well be dynamic, updates to the system graph must be con¬ 
trolled in order to continue to maintain its well-formedness. Additionally, as will be seen in 
Section [IJ there is great utility in supplementing the system graph’s relationship edges with ones 
derived during operation of the authorization system. Such additions must transform a system 
graph from one well-formed state to another. The extensions described in Section [4j introduce 
specific “system” types of edges to the model. 

2.2 Path Conditions 

In order to limit the administrative burden of defining access control policies in systems with 
many subjects, the RPPM model abstracts permission assignment to security principals (in the 
same way that roles simplify policy specification and maintenance in RBAC). To determine 
if a particular principal is relevant to a request, an associated chain of relationships must be 
matched between the subject and object of the request. Such chains of relationships are called 
path conditions. They are composed of relationship labels, organised as sequences, with support 
for several regular expression-like operators]]] 

Definition 3. Given a set of relationships R, we define a path condition recursively: 

• o is a path condition; 

• r is a path condition for all r £ R; 

• if 7T and tt' are path conditions, then ( 7 r), tt ; 7 t' , tt + and n are path conditions. 

A path condition of the form r or f, where r £ R, is said to be an edge condition. 

Informally, 7r ; tt' represents the concatenation of two path conditions; 7r + represents one or 
more occurrences, in sequence, of 7r; and Jf represents 7r reversed; o defines an “empty” path 
condition. (71) provides a means of clearly indicating the extent of path condition 7 r such that 
use of the Kleene plus operator is unambiguous. The satisfaction of a path condition is defined 
relative to a system graph G and two nodes u and v in the graph. 

Definition 4. Given a system graph G = ( V ., E) and u, v £ V, we write G,u,v (= 7 r to denote 
that G, u and v satisfy path condition 7 r. Then, for all G, u, v, tt, tt’ : 

• G, u, v (= o iff v = u; 

• G,u,v (= r iff (it, v, r) £ E; 

• G,u, v\= (tt) iff G,u,v\= n; 

• G,u,v \= tt ; tt' iff there exists w £ V such that G, it, w |= 7r and G , w, v |= tt' ; 

• G,u,v \= n + iff G,u,v \= tt or G,u,v \= tt ; n + ; 

• G,u,v \=n iff G,v,u \= n. 

1 The definition of path condition employs common regular expression operators, as do |13| and |26| . We 
exclude disjunction and the Kleene star for reasons described in Section 12.31 
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The compositional nature of path conditions, along with the regular expression-like operators, 
means that there is flexibility in how chains of relationships can be specified in a path condition. 
For example, the path conditions n ; 7r + and 7r + ; 7r are valid representations of the same chain 
of relationships - specifically, two or more instances of the relationship n. We now define what 
we mean by the equivalence of two path conditions, enabling us to define the concept of simple 
path conditions; henceforth, we will be assume all path conditions are simple. 

Definition 5. Path conditions tt and tt' are said to be equivalent, denoted tt = id, if, for all 
system graphs G = (V) E) and all u, v £ V we have 

G, u, v \= tt if and only if G,u,v |= tt' . 

Trivially, by Definition [3] and the definition of a symmetric relationship, we have (i) o = o; 

(ii) (7r) = 7 r for all path conditions 7r; (iii) s = s for all s £ S. We also have the following results. 

Proposition 1. For all path conditions 7Ti and tt 2 -’ 

(i) 7Ti ; o = o ; 7Ti = m; 

(ii) irf =WT + ; 

(iii) ff = 7Ti; 

(iv) 7Ti ; 7r 2 = 7fi ; 7fl; 

(v) (tt" 1- )" 1 " = 7T + ; 

(vi) 7T+ ; 7Tl = 7Tl ; 7T+ . 

Proof. All results follow immediately from Definitions [4] and [5] Consider (iv), for example. By 
definition, G,u,v |= 7Ti ; 7T2 if and only if G, v, u \= it \; 7T2. And G,v,u \= 7Ti; 7T2 if and only there 
exists w such that G,v,w \= 7Ti and G,w,u \= tt 2 - Thus we have G,u,v |= 7Ti ; 7T2 if and only if 
there exists w such that G,w,v \= and G,u,w \= tt^. That is G, u, v \= tt 2 ; 7rf. □ 

Definition 6. Given a set of relationships R, we define a simple path condition recursively: 

• o, r and r, where r £ R, are simple path conditions; 

• if 7r ^ o and n' ^ o are simple path conditions, then (tt), tt ; tt' and 7r + are simple path 
conditions. 

In other words, * occurs in a simple path condition if and only if * is an element of R. It 
follows from Proposition[l]that every path condition may be reduced to a simple path condition. 
The path condition ?q ; r 2 ; (rq ; f 3 ) + , for example, can be transformed into the equivalent path 
condition (rq ; rT) + ; r\ ; rq using the equivalences in Proposition [1] 

Remark 1. Henceforth, we assume all path conditions are simple. Thus we may define the set of 
relationship labels to be R = RUR, where R is defined to be {r : r £ R}. Given this formulation, 
the system graph must satisfy the following consistency requirements: 

• ( t,t',r ) e E pr if and only if (t‘,t,r) £ E PR ; 

• (v, v', r) £ E if and only if (v 1 , v, r) £ E; 

• (n, v', s) £ E if and only if ( v ', v , s) £ E. 
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2.3 Policies 


The RPPM model employs two policies: the principal-matching policy and the authorization 
policy. The purpose of the principal-matching policy is to determine which principals are relevant 
to an access request. The purpose of the authorization policy is to determine the actions for 
which a principal is authorized. 

An authorization principal is, therefore, a central component in RPPM policies. A request 
is mapped to a set of principals and each principal is authorized to perform particular actions. 
In other words, principals are analogous to roles in a role-based access control (RBAC) model. 
However, the way in which principals are associated with subjects is very different from RBAC. 

A second important component is a target. Each principal-matching rule specifies two targets. 
Every path condition 7r is a target and we say a request (s, o, a), where s and o are vertices in the 
system graph G (and a £ A is a requested action), matches target n if G, s, o |= tt. We define two 
special targets: all and none, where all matches every request and none matches no request. By 
a slight abuse of notation (all and none are not path conditions), we will write G, s,o \= all and 
G,s,o none, for any request (s, o, a). Given a request q = ( s , o, a), where s and o are vertices 
in the system graph G, we will write G, q \= n, rather than G, s, o |= 7r, to simplify notation. 

Definition 7. Let P be a set of authorization principals. A principal-matching rule has the 
form (<f,if,p), where p £ P and <fi and if are targets. A principal-matching policy is a set of 
principal-matching rules. 

Informally, targets are used to determine which rules are applicable to a given request, where 
</> specifies a required path in the system graph and if specifies a forbidden path. The meaning 
of a principal-matching policy (PMP) is defined in the context of a system graph and a request. 

Definition 8. We say a principal-matching rule ( <f,if,p ) is applicable to a request q = ( s,o,a ) 
if and only if G, q \= <f and G,q ^ if. Given a system graph G = (V, E), a PMP p and a request 
q = (s,o,a), where s,o £ V, we define the set of matched principals: 

[pjj^ d = {p £ P : ((f,if,p) £ p is applicable to q} . 

Henceforth, G will be assumed to be given, so we will simply write \p\ q to denote the set of 
matched principals for policy p and request q. We will further abbreviate this to [p]| when q is 
obvious from context. 

Remark 2. Path conditions are clearly closely related to regular expressions. However, we do 
not include disjunction or the Kleene star operator in our definition of path conditions. Instead, 
we use two (or more) principal-matching rules. The path condition 7r* ; tt', for example, can be 
associated with a principal p by specifying the principal-matching rules (7r',none,p) and (7T + ; 
tt', none,p). This approach is preferable to including these features as they’re inclusion would not 
increase the expressiveness of the policy language but would introduce greater complexity into the 
request evaluation process discussed in Section cdE 

Remark 3. A PMP may specify a default principal pdef, much like the concept of “world” in 
the Unix access control system. To do so, we include the principal-matching rule (all, none,pd e f)- 

Definition 9. An authorization rule has the form (p,x,y,b), where p £ P, x £ O GT G {*}, 
y £ A U {*} and b £ {0, Given a PMP p, an authorization rule (p, x, y, b) is applicable to a 
request q = (s, o, a) if all of the following conditions hold: 

2 Specifically we would require an additional NFA construction mechanism for each. 

3 Recall T is the set of entity types. 
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• P6 M> 

• X £ {o, t(o),*}; 

• y£ {a,*}. 

An authorization policy is a set of authorization rules. Given an authorization policy g and a 
request q = (s,o,a), we define the set of authorization decisions: 

\p, ol^ *= f {b £ { 0 , 1 } : (j>, x, y,b) £ g is applicable to q] . 

The rule (p, o, a, 1) indicates that principal p is authorized to perform action a on object o, 
while ( p , o, a, 0) indicates p is not authorized. The wild card character ★ is used to simplify the 
specification of policies. It can be used, for example, to authorize a principal for all actions on a 
given object. We can then prohibit specific actions using a negative authorization tuple. Thus, 
the inclusion of (jp, o, ★, 1) and (j>, o, a, 0) in the policy authorizes p for all actions on object o, 
except action a. 

The ability to specify object authorization rules for individual objects o or all objects * 
provides for flexible policy creation. However, in some circumstances these two extremes may 
not be appropriate. Support for authorization rules specified in terms of object types goes 
some way to balancing these two alternatives. The rule {p,t,a, 1) indicates that principal p 
is authorized to perform action a on all objects of type t , whilst (p, t, a, 0) indicates p is not 
authorized. 

Again, we will simply write \p, gj q to indicate the set of authorization decisions for policy g 
and further abbreviate this to [p, pj| when no ambiguity will arise. 

Example 1 . Returning to our higher education example from Section |7J we can envisage a 
system that includes a PhD student u\ and professor U 2 , courses C\ and C 2 , coursework answers 
ai and a 2 for course Ci, and coursework answer 03 for course C 2 (illustrated by the system graph 
fragment shown in Figure \fi). 



Figure 1: A fragment of the system graph for the higher education use case 

It is natural that we would wish to constrain the PhD student from accessing answers (other 
than their own) for courses on which they are enrolled as a student, whilst we would wish to grant 
access to those for courses for which they are a teaching assistant. To do so requires the ability 
to distinguish the context (in this case the course) associated with a request. We can achieve this 
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in the RPPM model through the specification of the following policies: 
p = {( is-creator-for, none, author ), 

( is-ta-for ; is-coursework-for, is-enrolled-on ; is-coursework-for, course-ta ), 

( is-responsible-for; is-coursework-for, none, course-leader )} 
p = {(author, *, read, 1), ( author, ★, write, 1), ( course-ta, *, read, 1), (course-ta, *, grade, 1), 
(course-leader, ★, read, 1), (course-leader, ★, review, 1)} 

We will consider request evaluation in more detail in Section 0 However, the intuition behind 
request evaluation is that we determine whether, for a given request and system graph, there is a 
path in the graph from subject to object for which the associated labels match the path condition. 
Consider the request (u\,a\, read), for example. There is no path in the graph between u\ and a± 
that matches any of the mandated targets in rules within p. Thus, the set of matched principals 
is empty (which will lead to the request being denied, assuming a deny-by-default discipline). On 
the other hand, the set of matched principals for request (u\,a 2 , read) is {author}, since there is 
a path from u\ to a 2 with label is-creator-of; hence the request will be granted (because of the first 
rule in g). However, the set of matched principals for request (1x1,03, read) is {course-ta} and 
the request will be permitted (because of the third rule in g). Note the difference in outcomes for 
requests (u\,a\, read) and (u±, as, read) because of the different relationships that exist between 
u\ and the courses associated with objects a± and a 3. Similarly, the set of matched principals 
for (u 2 ,a\, read) and (U 2 , <22, read) is {course-leader} and these requests will be granted, whereas 
the set of matched principals for (1x2,03, read) is empty (and the request will be denied). Again, 
the professor’s relationship with the two courses determines the principals (and thus decisions) 
associated with the respective requests. 

2.4 Policy Extensions 

We now describe additional refinements of principal-matching policies and authorization policies. 
Most importantly, we indicate how we deal with a set of decisions that is not a singleton and 
how we can provide support for principal activation rules. 

2.4.1 Conflict Resolution 

The authorization rule (p, o, a, 0) explicitly disallows p from performing action a on object o, 
while (p, o, a, 1 ) explicitly allows it. Thus, the set of applicable authorization decisions may 
contain conflicting decisions. 

Accordingly, we define an extended authorization policy to be a pair (g, y), where g is a set 
of authorization rules and X is a conflict resolution strategy (CRS) which is used to reduce the 
set of matching decisions to a single decision. That is, \p, (g, y)] £ {{0} , {1}}. In the interests 
of brevity, we will continue to write \p, p] in preference to \p, (g, y)]. 

The DenyOverrides CRS reduces the set to a single deny (0) decision if there is at least one 
0 in the set of matching authorization decisions. Conversely, AllowOverrides reduces the set to a 
single allow decision if there is at least one 1 in the set. 

2.4.2 List-oriented Policies 

The meanings of a principal-matching policy and an authorization policy are defined in terms of 
sets. A number of access control systems are list-oriented, in the sense that the first applicable 
decision is used, the Unix access control mechanism being one example. We could equally well 
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require that rules in PMPs and authorization policies are evaluated in a particular order. (That 
is PMPs and authorization policies should be lists, rather than sets, of rules.) 

In this case, it would make sense to introduce list-oriented processing. In particular, we 
might insist that we take the first matched principal, so the meaning of a PMP becomes a single 
principal. Similarly, we might insist that we take the first matching authorization decision (so 
we would not require conflict resolution). 

If a list-oriented approach is employed, then the default principal-matching rule 
(all, none,pdef) must be placed at the end of the list of principal-matching rules. 

2.4.3 Graph- and Tree-based Policies 

Principal-matching rules make use of two targets (one mandated and one precluded). These 
targets are evaluated when deciding whether a request is to be permitted or not. As we have 
seen, we can support disjunction, where a principal is activated if at least one of several path 
conditions is satisfied, through the use of multiple principal-matching rules for the same principal. 
There may also be times when there is a need to match a security principal only if each one of 
several path conditions is satisfied. The basic RPPM policy model described above does not 
support this requirement. 

Hence, we introduce the idea of a policy graph. We arrange the rules in a PMP as a directed 
acyclic graph, making the process of matching principals more like the evaluation of XACML 
policies. More formally, a policy graph is a directed acyclic PMP graph Gpmp = (IpmPi^pmp)- 
The PMP graph is required to have a unique node of in-degree 0, which we will call the root. 
Each vertex in the PMP graph is a PMP rule. It is convenient, in this setting, to define a null 
principal; the null principal must not appear in any authorization rules. 

Evaluation of the PMP graph is performed by a breadth-first search. A vertex v (that is, a 
PMP rule) is only evaluated if the request is applicable to each PMP rule on every path from 
the root to v. (Of course, if we insist that the PMP graph is a tree, there is only one such path.) 
As before, the set of matched principals is simply the set of principals associated with applicable 
rules. 

It is easy to see that our list-oriented policies can be represented in this wayd However, this 
graph-based approach also makes it possible to encode principal activation rules of the form “if p 
is applicable to a given request then so is principal p ,v . Moreover, we can insist that a principal 
p is only activated if multiple path conditions 7Ti,..., n n are satisfied. 

Consider the simple policy graph in Figure [2] Then (ignoring the null principal which has no 
authorizations) the set of matched principals may be one of 0, {pi}, {P 2 ,P 4 }> or {pi,P 2 ,P 3 ,Pi}- 
In particular, p 4 is activated if p 2 is, because the path conditions associated with p 2 are satisfied 
(and the targets associated with p& are trivially satisfied); and if both p\ and P 2 are activated 
(because their respective path conditions are satisfied) then so is P 3 (as well as jq). 

2.5 Default Decisions 

A default access control decision (allow or deny) needs to be specified in the event that no 
authorization rules apply to a request. Systems may need to support allow-by-default when the 
system enters an emergency state, such as the opening of fire exit doors when there is a fire. 
Other circumstances will commonly require fail-safe handling, where a deny-by-default strategy 
is implemented in order to ensure no unauthorised access is allowed. Some systems may be 
deemed so sensitive that there may be no conditions under which allow-by-default would be 
enabled. 

4 We define a tree with root node (all, none, null) and each PMP rule is a child of the root node. 
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(all, none, null) 



(all, none, p 3 ) (all, none, pi) 

Figure 2: A graph-based PMP 


There are two circumstances in the RPPM model when default decision-making applies. The 
first is when no matched principals are identified ([pj = 0), whilst the second is when there 
are no explicit authorisations (|p, p] =0). Accordingly, we allow for default decisions to be 
applied at one of the following levels: default-per-subject, default-per-object, default-per-type or 
system-wide default. The default-per-subject decision is only applied when there are no matched 
principals @ 

The four defaults are evaluated in order, where specified, with the first applicable default 
determining the authorization decision. In this way, if there is a default specified for the subject 
s of the request (s,o,a), the subject’s default (allow or deny) applies. If no subject default is 
defined for s, then the default for the object o of the request shall apply, if specified. If there 
is no subject default for s and no object default for o, then the default for the type of object 
r(o) shall apply. If none of these defaults are defined, then the system-wide default shall apply. 
Defaults for the subject, object and type are optional and need not be specified for the entities 
involved in the request. However, a system-wide default must be specified in order to ensure an 
authorization decision can be made for every request. 


3 Request Evaluation 

Request evaluation uses a two-step process, as shown in Figure [3] where first we compute prin¬ 
cipals and subsequently compute authorizations. This two-step request evaluation process is 
inspired by Unix, which first determines the relevant principal (from “owner”, “group” and 
“world”) and then authorizations (from the permission mask of the object). 



Figure 3: Processing overview 

Figure [I] provides a detailed architecture of the complete request evaluation process, indi¬ 
cating the inputs necessary and decisions employed; the figure includes the conflict resolution 
extension described in Section 12.4.11 The first step of request evaluation, compute principals, is 
rather complex and, conceptually, requires the identification of paths within the system graph in 
order to determine the principals which match a request. However, the second step, compute au¬ 
thorizations, involves simple lookups to determine whether the matched principals for a request 
are authorized to perform the requested action on the object. 

5 It is not applied when there are no explicit authorizations: when the set of possible decisions is determined, 
the subject is no longer relevant, having been used to identify the appropriate matched principals. 
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Figure 4: Detailed architecture 


Pseudo-code for the entire request evaluation process is shown in Algorithm [Q The Apply- 
Defaults functionality can be inferred directly from the default decision handling discussion in 
Section [2.51 so no formal algorithm is required or provided here. 

We determine the set of matched principals using Algorithm [2] (ComputePrincipals). The 
required processing is described in more detail in the next section. Briefly, we exploit the cor¬ 
respondence between path conditions and regular expressions to build a non-deterministic finite 
automaton M n for path condition 7r; and we use the correspondence between labelled graphs 
and non-deterministic finite automata to construct a non-deterministic finite automaton Mo, q 
derived from the system graph G and information in a request qd For brevity, we will write 
M q for Mc, q , as G will always be obvious from context. We use these non-deterministic finite 
automata to determine whether each principal-matching rule is applicable to a request, and 
whether its principal is, therefore, matched. 

Having identified the set of matched principals, the set of authorizations can be easily 
determined from the applicable authorization rules (as per Definition [9| using Algorithm [3] 
(ComputeAuthorizations). This process is far simpler than that of Algorithm [2j being limited 
to simple comparisons and set membership checks. Lines 7 through 11 of Algorithm [3] provide 
for conflict resolution as described in Section 12.4.11 

6 In a preliminary version of this paper we made use of a (modified) breadth-first search algorithm to deter¬ 
mine whether a target (from within the principal-matching rule) was matched within the system graph 1161 ■ In 
this paper, we make use of the rich theory underpinning regular expressions and finite automata to provide an 
alternative algorithm based on rigorous foundations. 
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Algorithm 1 RequestEvaluation 

Require: System graph G = (V,E), set of relationship labels R , request (s,o, a), principal-matching policy p 
and extended authorization policy ( q , x) 

Ensure: Returns authorization decision 
1: [p] = ComputePrincipals(G, R, (s, o, a), p) 

2: if [p] = 0 then 
3: return ApplyDefaults(s, o) 

4: else 

5: [p, f?] = ComputeAuthorizations((s, o, a), (g, y), [p]) 

6: if Ip, p] = 0 then 

7: return ApplyDefaults(o) 

8: else if [p, p] = {0} then 

9: return false // deny 

10: else if [p, p] = {1} then 

11: return true // allow 

12: end if 

13: end if 


Algorithm 2 ComputePrincipals 

Require: System graph G = ( V , E), set of relationship labels R, request (s, o, a) and principal-matching policy p 
Ensure: Returns set of matched principals [p] 

1: [p] = 0 

2: M q = ( V,R,E,s,{o }) 

3: for ((f), ip,p) G p do 

4: if (cf) = all) or (L(M^) fl L(M q ) / 0) then 

5: if ( , 0 = none) or (L(M^) D L(M q ) = 0) then 

6: [p] = [p] U p 

7: end if 

8: end if 

9: end for 


Recall that we may define more complex graph-based policies, in which the principal-matching 
rules are arranged in an acyclic directed graph. Accordingly, we would need to modify the request 
evaluation algorithm to ensure that we identify all matched principals. Informally, this means 
the ComputePrincipals algorithm becomes a breadth-first search of the policy graph which calls 
a sub-routine for testing path conditions at each node visited. 

3.1 From Path Conditions to NFAs to Principal Matching 

We now describe the correspondence between path conditions and non-deterministic finite au¬ 
tomata in more detail. We also explain how to define the automaton M q given a system graph G 
and a request q. Finally, we explain how to construct an automaton that will determine whether 
a request q matches a path condition n (in the context of a system graph G ). 

A non-deterministic finite automaton is a 5-tuple M = (Q, S, <5, s, F) where: 

• Q is the set of states, 

• S is the set of inputs (the alphabet), 

• SQQxQxT, is the transition relation, 

• s € Q is a start state and F C Q is the set of accepting states. 

Let ui = <j\... <ji, where cq 6 S, be a word over the alphabet E. The NFA M accepts word ui if 
there exists a sequence of states, qo,..., qt_ such that: 
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Algorithm 3 ComputeAuthorizations 

Require: Request (s,o, a), extended authorization policy (p, x) and set of matched principals [p] 
Ensure: Returns set of authorization decisions [p, p] 

1: |p>e] = 0 

2: for (p, x, y,b) G g do 

3: if (p G [p]) and ((rr = o)or(r = r(o))or(rc = *)) and ((y = a)or(y = *)) then 

4: Ip, el = [p, el u b 

5: end if 

6: end for 

7: if (x = DenyOverrides) and (0 G [p, p]|) then 
8: [p, el = {o} 

9: else if (x = AllowOverrides) and (1 G [p, p]) then 
10: [p,e] = {l} 

11: end if 


• s = qo and qt G Q for i > 0; 

• (qi,q i+ i,a i+1 ) G <5 for 0 < i < i — 1; 

• Qe G F. 

We write L(M) to denote the set of words (or language ) accepted by M. 

Given two NFAs, Mi = (Q±, Si, <5i, si, _Fj) and M 2 = (Q 2 , S 2 , S 2 , s 2 , F 2 ), the intersection NFA 
M n = (Q 1 x Q 2 , Si nS 2 ,^n,(si,s 2 ),Fi x F 2 ) accepts the language L{M\) C\L(M 2 ), where 

<5n = {((gi, 92 ),(gi,g 2 ),cr) : (qi,q[,<7) G 5 1 ,{q 2 ,q' 2 ,a) G <5 2 } ■ 

3.1.1 Path Conditions as NFAs 

We now explain how to construct an NFA for a path condition. The construction is straightfor¬ 
ward and is based on standard techniques (see, for example, [5]), given the obvious similarities 
between path conditions and regular expressions. 

Proposition 2. Let r G R and let 7 r and <fi be path conditions with NFAs M , T = 
(Q 7 r,S w ,( 5 x ,s T ,{/ T }) and M$ = (Q^, S^, 8$, s#, {/</,}) accepting languages L(M , r ) and L{M$), 
respectively. Then 

• M r = ({s, /} , M , {(s, /, r)} , s, {/}); 

• A Ar;^ — S^ U S 0 , Srr, , where — t^ 7 r U \ and 

Sntf = S n U 6$ U {(/*■, q, r) : (s^, g, r) G 5^} \ {(x, y, z) G 64, : x = s^} ; 

• M 1 r+ = (Q,r, S w U {e} , S n +, Sn , {/tt}), where e is the empty symbol and 

^ 7 r+ = $77 U {(/ 7 r, SV, e)} . 

By construction, every NFA will have a single final state. Moreover, because we do not 
include disjunction in path conditions, there is a unique transition from the initial state. The 
constructions of M r , M X| ^ and M w + are illustrated in Figure [5] 

The construction of the intersection NFA is simpler if the component NFAs do not contain 
empty transitions. Accordingly, we modify the NFA for M n + to remove the empty transition. 
Since every NFA representing a path condition has a single transition from the initial_state, we 
may assume that we can write any path condition 7r o in the form r ; n', where r G R. Hence, 
we may represent 7 r + by the NFA shown in Figure I6al In the special case that 7 r = r for some 
r G R, 7r' = o and the start and final states of 7 r' coincide, as shown in Figure l6bl 
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start 



(a) M r 



Figure 5: Schematic representations of NFAs for r, 7r ; <j> and 7r + 



Figure 6: M n + without the empty transition 


Example 2. Consider the path condition 


(ri;r^ ; (n ; r 3 )+. 

Then, we may transform this into a simple path condition using the rules in Proposition QJ 


(n ; r^)+ ; (n ; r 3 )+ = (n ; r 3 ) + 

; (n;r^j 

= (n ; r 3 ) + 

; (n ; r+ J 

= (J3 ; 7T) + : 

; (n ;r^) 4 


The corresponding NFA is shown in Figure Note the number of states is 5 and the number of 
transitions is 7. In Section \3.‘A we establish the way in which the number of states and transitions 
vary with the structure of n. 


start 


r 3 ri 



Figure 7: The NFA for (r 3 ; n) + ; (n ; r^") + 


3.1.2 Principal-matching 

The set of matched principals for a request is determined by identifying those principal-matching 
rules that are applicable to a given request q = (s, o, a). Recall that a system graph G = ( V ., E) 
contains a set of nodes V and a set of edges E C V x V x R, where R is the set of relationship 
labels. Given a request q = (s,o,a) and the system graph G = (V,E), we define the NFA 
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M q = (V, R, E, s, {o}). Thus, every labelled edge in G defines a transition and the start and final 
states are s and o, respectively. 

It is trivial to decide whether a request matches the all and none targets. Hence, we only 
consider targets that are path conditions. Informally, given a path condition 7r, a request q and 
a system graph G, we wish to find a path in the directed graph G (equivalently a word accepted 
by M q ) that is also a word accepted by M„. Thus, for a principal-matching rule (<p,ip,p) to be 
applicable to a request, where <p and ip are path conditions, we require cp to be matched by the 
request and ip to not be matched. Therefore, we compute L(M ^) fl L{M q ) and L(M$) f~l L(M q ); 
the former must be non-empty and the latter must be empty. We test these language properties 
by constructing two intersection automata, one from M$ and M q , the second from M.^ and M q . 

3.2 Complexity 

The algorithms ComputeAuthorizations and RequestEvaluation do not involve significant compu¬ 
tation. The worst case time complexity of request evaluation is, therefore, dominated by the 
complexity of ComputePrincipals, which is dependent on two things^ 

• the number of principal-matching rules to be evaluated; and 

• the complexity of determining whether the intersection NFAs accept non-empty languages. 

To evaluate the second of these factors, we define the length t(j t) of a (simple) path condition n 
to be: 

• £(j r) = 1 if 7r = r for some r £ R; 

• t(j r ; 7r') = £(tt) + £(n')', 

• £(j r + ) = £(tt). 

In other words, £(n) is simply the number of occurrences of elements in R in n. We now consider 
the size of the NFA M v . 

Proposition 3. Let r £ R, n and <p be path conditions. Then: 

• \Q r \ = 2 and |<5 r | = 1 for r £ R; 

• — |f?7r| T 1 and | ^7r; cj) | — | Att | T |^|, 

® I7r-eI — and |-t-1 — |^7r| T 1- 

Proof. The proof follows immediately by inspection of the NFAs in Figure [5] □ 

Corollary 1. Let n be a simple path condition and let denote the number of occurrences 
of + in 7r. Then for path condition n, \Qk\ = £(ir) + 1 and |(5 W | = £(ir) + 

Proof. The result may be proved by a straightforward induction on the structure of n. Clearly, 
the result for \Qtt\ holds for path condition tt = r, r £ R. Now consider path condition 7r; cp and 
assume the result holds for 7r and (p. Then 

IQ^I = \Q-k\ + \Q<j>\ — 1 = (■^( 7r ) + 1) + {£((p) + 1) — 1 = £(tt ; 4>) + 1, 

7 The NFAs for path conditions contained in rules in the PMP can be pre-computed once and used, as required, 
to construct the intersection automata. 
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as required. Finally, consider path condition 7r + and assume the result holds for 7 r. Then 

\Qn+\ = IQttI = t{n) + 1 = Z(k + ) + 1. 

Similarly, the result for |J,r| holds for path condition 7 t = r. Now consider path condition 7 r;(f> 
and assume the result holds for n and </>. Then 

\$n-,<f>\ = |<M + |<VI = t(n) + i?(tt) + £{4>) + M ; </>) + $(tt ; </>)■ 

Finally, consider 7r + and assume the result holds for 7 r. Then 

|<5„.+ | = |5tt[ + 1 = + 1 = + ^(7T + ). 


□ 

The complexity of computing the intersection NFA for NFAs M and M' is determined by 
the size of the respective transition relations, since we compute a product automaton whose 
transition relation is determined by the transition relations of the component NFAs. In the 
worst case, the size of transition relation dCQxQxEis 0(|<3| 2 • |£|). However, in the case 
of our path condition NFAs, we have |<5„.| = £(n) + i9(7r). The size of the transition relation in 
M q is 0(|I?| • \y\ 2 )- Thus, the overall complexity of evaluating a path condition 7r with respect 
to a request and system graph G is + $(n)) ■ |i?| • |V| 2 ). Each principal-matching rule 

contains at most two path conditions as targets. And each principal-matching rule in policy p 
must be evaluated. Thus the overall complexity of evaluating a request is 0(\p\ ■ •d(p) • \R\ ■ \V\ 2 ), 
where $(p) = max {^(7r) + $(7r) : n € p}[f| 

3.3 Target-based Request Evaluation 

The request evaluation process described above evaluates every principal-matching rule to iden¬ 
tify those principals applicable to a request. It subsequently determines whether those principals 
are authorized to perform the requested action on the object. This process is rather inefficient, 
as one or more of the principals matched in this way may not appear in any authorization rules 
associated with the requested object. Accordingly, we now briefly consider ways in which the 
request evaluation process could be improved. The natural approach is to use “target-based” 
evaluation of requests, as exemplified by XACML L 33] and other target-based languages mam. 

We outline a simple target-based strategy, leaving further development for future work. Given 
a request (s,o,a), the only principals that can be relevant to evaluating the request are those 
that appear in rules of the form (p,x,y,b), where x £ {o,r(o),*} and y £ {a,*}. The resulting 
list of principals can be used to limit the principal-matching rules that are evaluated. In the 
worst case, of course, we still have to evaluate the entire set of principal-matching rulesj^l 

4 Typed Edges 

The basic RPPM model, described in the previous sections, offers a general model of relationship- 
based access control which naturally supports contextual information. It can be employed to de¬ 
scribe structurally simple social network systems or online social networks [H EMU]. However, 

8 In our previous work we had made use of a (modified) breadth-first search algorithm which resulted in a worst 
case time complexity of request evaluation of 0((|p| • £(p) • |V|) + (|p| • \R\ • |V| 2 )) m- 

9 Target-based request evaluation as described is only applicable for list-oriented policies (not for graph-based 
policies). Nevertheless, it is straightforward to modify target-based evaluation to work in conjunction with policy 
graphs. We omit the details, again deferring this for future work. 
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the RPPM model can equally well describe far more complex systems representing individual 
computers, computer networks and organisations m- Whilst the basic RPPM model can cover a 
wide range of systems, the compute principals step of request evaluation may be computationally 
intensive for very large system graphs or systems employing principal-matching policies which 
contain a very large number of rules. Additionally, it may be necessary for an implementation 
to support certain useful policy frameworks within the access control model. For example, rep¬ 
utation and history-based access control (HBAC) systems rely on knowledge of previous actions 
to inform decisions mas eu. More generally, workflow systems may use previous activity to 
enforce constraints such as separation of duty [23, 35J and “Chinese Walls” [8]. 

In order to broaden the applicability of the model and to improve the performance of request 
evaluation, the basic RPPM model can be extended to support typed edges , where each edge in 
the system graph has a type. 

• Relationship edges are the standard edge type and are labelled from the basic model’s set 
of relationship labels R ; 

• Caching edges enhance the performance of request evaluation processing and are labelled 
with a set of principals; 

• Decision audit edges record the decisions from previous authorization requests and are 
labelled with an indication of whether a requested action a was authorized a® or denied 
a® to a subject on an object; 

• Interest audit edges record a subject’s active or blocked interest, i®or i e respectively, in an 
entity. 

Whilst relationship edges may be directed or undirected, edges of the other types are always 
directed away from the relevant subject. 

Relationship edges are the foundation of the system graph, representing relationships between 
entities in the system. When a system is first described using the RPPM model, the system graph 
will only contain relationship edges. As requests are made and evaluated, edges of the other types 
may be added to the system graph and can, therefore, impact future request evaluations. Whilst 
the existence of decision and interest audit edges can alter the outcome of request evaluation, as 
discussed in Section [~P1 and roi the existence of caching edges may simply allow the first step 
of request evaluation to be bypassed, thus speeding up request evaluation without altering the 
final decision which results. 

4.1 Caching Edges 

The first step of request evaluation, described in Section ETT1 determines the set of matched prin¬ 
cipals which apply to a request. The target-based optimisation for request evaluation, described 
in Section 13.31 offers a potential reduction in the processing required during the compute prin¬ 
cipals step. However, the benefit is limited to simply excluding some of the principal-matching 
rules during the evaluation of individual requests. Which rules, if any, that are excluded varies 
with each request but the remainder must be processed as before. However, note that the set 
of matched principals for a subject-object pair remains static until a change is made to the 
system graph or certain associated policy components. This observation suggests a more widely 
applicable optimization. 

Accordingly, we introduce the concept of caching edges and make use of the relative stability of 
matched principals in order to reduce the processing required for future authorization requests. 
In particular, when we evaluate a request (s, o, a) that results in a set of matched principals 
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[p] C P, we add an edge (s, o, [p]) to the system graph, directed from s to o and labelled with 
[p]; this edge identifies the matching principals relevant to future requests of the form ( s,o,a'). 
The processing of subsequent authorization requests of the form (s, o, a') can, therefore, skip 
the computationally expensive step of computing the matched principals and instead use JpJ in 
conjunction with the authorization rules to evaluate requests of this form. Recall that the action 
of a request is not part of the compute principals step of request evaluation. 

Example 3. Recall that u\ is the teaching assistant for course C 2 and is thus associated with the 
principalP 2 and authorized to read and grade 03 . Suppose that u\ makes the request (iii, a 3 , read). 
Then this request will be authorized because [p] = {^ 2 }- At this stage, we may therefore add 
an edge (ui, as, {^ 2 }), thereby caching the outcome of the principal-matching phase of request 
evaluation, as illustrated in Figure\B 1 Then a subsequent request [u\,az, grade) will only need to 
determine that P 2 is associated with the subject-object pair (ui, 03 ) and can immediately evaluate 
the authorization rules (and thereby authorize the request). 



Figure 8: Adding a caching edge 


4.1.1 Cache Management 

Whilst the performance improvement offered by caching edges may be significant, there is a need 
to carefully manage any implementation of caching edges to prevent this improvement being 
countered by an indiscriminate increase in the number of edges in the system graph. In the 
worst case, the number of caching edges directed out of a node is 0(|Vj), where V is the set 
of nodes in the system graph. However, there are strategies that can be used to both prevent 
the system graph realizing the worst case and to reduce the impact of large numbers of caching 
edges. To maintain an acceptable number of caching edges, we could, for example, use some form 
of cache purging m- Further experimental work is required to determine how best to make use 
of caching edges. 

4.1.2 Preemptive Caching 

Any optimisation provided by the caching of matched principals relies upon the existence of a 
caching edge in order to reduce the authorization request processing. The first request between 
a subject and object must, therefore, be processed normally in order to determine the set of 
matched principals which will label the caching edge. If this initial evaluation were only per¬ 
formed when an authorization request were submitted, then the benefit of caching edges would 
be limited to repeated subject-object interactions alone. 

However, many authorization systems will experience periods of time when no authorization 
requests are being evaluated. The nature of many computing tasks is such that authorization 
is required sporadically amongst longer periods of computation by clients of the authorization 
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system and idle time for the authorization system itself. These periods of reduced load on the 
authorization system can be employed for the purpose of preemptive caching m- Again, further 
experimental work is required to evaluate how best to perform preemptive caching. 

4.2 Decision Audit Edges 

The basic form of the RPPM model is “memoryless” with respect to request evaluations. The 
introduction of decision audit edges allows the system to record whether previously requested 
actions were authorized or denied. Both authorized and denied decision audit edges are inserted, 
automatically, into the system graph after request evaluation completes. If such an edge does 
not already exist, a decision audit edge is added between the subject and object of the evaluated 
request, indicating its result 0 

These edges can be utilised in a variety of ways depending on the requirements of the autho¬ 
rization system. At their simplest, they provide a record which may be used as input for auditing 
or other processing outside of the authorization system^ Within the authorization system, de¬ 
cision audit edges can be used to match part of a path condition, thus enabling authorization 
decisions to be made based on historical evidence. 

The caching edges we introduced in the previous section arise from the principal-matching 
part of the request evaluation process. An audit edge arises from the second phase of the 
evaluation process. We extend the set of relationship labels by defining the relationships a® and 
a® for each action a. 

• If the decision for request (s,o,a) is allow, then we add the edge (u, o, a®) to the system 
graph. 

• Conversely, if the decision for request (u, o, a) is deny, then we add the edge (u, o, a e ) to 
the system graph. 

Principal-matching rules can be created to make direct use of decision audit edges. Some 
obvious examples include: 

• the principal-matching rule (all, a®,p) can be used to match the principal p to any request 
where the subject has not previously performed the action a on the object; 

• the rule (all, a®,p) requires that the subject has never been denied action a on the object; 

• the rule (a®, none, p) requires that the subject must have previously had a request to 
perform action a on the object approved. 

Example 4. Returning to our higher education example, suppose that we have a student u$ who 
is enrolled on course C 2 and is the author of coursework 03 . Then u\, the teaching assistant 
for the course will, at some point, grade the coursework 03 . At this point, U 3 should not be 
able to modify 03 . We could enforce this requirement by modifying the principal-matching rule 
(r4,none,pi) — which assigns any user who is the owner of a piece of coursework to the author 
principal—to (n, r\ ;r 3 ; grade®,p±). This rule includes a second path condition r^yr^',grade®, one 
that must not be matched if the principal pi is to apply to a request. This path condition traces 
a path from enrolled student to course to teaching assistant to (graded) coursework. Figure 0 

10 In some situations there may be merit in recording every occurrence of an action (by a subject on an object) 
being authorized or denied. Modifying the decision audit edge’s label to include a count would be a simple way 
of achieving this if it were required. 

11 In this form they may, for example, be used to identify potentially malicious actors. A node with a large 
number of, or a sudden increase in, denied decision audit edges may be considered worthy of further investigation. 
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illustrates the system graph once the teaching assistant has graded 03 ; we represent allow audit 
edges using dashed lines. Note that there is a path from U 3 to 03 matching the prohibited path 
condition. 

Of course, in practice U 3 will still wish to read 03 , so we might wish to specify a sep¬ 
arate rule, rather than modify the existing rule. This separate rule could have the form 
(r± ;r£; grade ®, none, p) and then we specify an additional authorization rule (p , *, write, 0 ) which 
explicitly denies principal p write access to any object. 



Figure 9: Using audit edges to enforce complex policy requirements 


4.2.1 Separation of Duty 

Whilst decision audit edges can be used in an ad hoc manner to enforce application-specific 
constraints, we can also use them to enforce separation-of-duty in a systematic way. Separation 
of duty requires that certain combinations of actions are performed by a number of distinct 
individuals so as to reduce the likelihood of abuse of a system. In its simplest form, separation 
of duty constraints require two individuals to each perform one of a pair of distinct actions so 
that a single individual cannot abuse the system. A common application environment for such 
constraints is that of a finance system, where, for example, the individual authorized to add 
new suppliers should not be the same individual who is authorized to approve the payment of 
invoices to suppliers. If a single individual were able to perform both of these actions they could 
set themselves up as a supplier within the finance system and then approve for payment any 
invoices they submitted as that supplier. 

We define a mechanism here through which n (distinct) users are required to perform n 
actions associated with an object. Let us consider the system graph G 2 (see Figure filial) , a set 
of actions A = {ai,..., a m }, m ^ n, and the following policies 

P = {(A none,p)} 

0 = {(p, o,*, 1)} 

% = DenyOverride 

With these policies (whether we use audit edges or not), if individual u\ makes the request 
qi = (ui,o,cii) this will be authorized by matching principal p , as will subsequent requests 
<?2 = (ui, 0,(12) and <j3 = (111,0,03). A similar result would have occurred if these requests had 
been submitted with u 2 or U3 as the subject. 

Now suppose we wish to restrict each user to a single interaction with o. Then we define the 
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(a) system graph fragment (b) after request qQ = (u 2 , 0 ,( 13 ) 

Figure 10: Adding decision audit edges 


policies 


p' = {(of, none, :l<s^n}Up 
p' = {(j>i,o,a,j, 0) : 1 < * < n, j / *} U g 


Then, assuming there are no audit edges in the system graph, request (ui,o, ai) matches the 
rule in p , as before, and the request is authorized by the rule in g. However, assuming the audit 
edge of) is now added to the system graph, a subsequent request ( 01 , 0 , 02 ) will match 

the new rule (a®, none,pi), leading to a deny decision (because of the new rule (pi, o, 02 , 0)). At 
this point a deny audit edge will be added to the system graph. Similarly, request (iti, o, 03 ) will 
be denied, and any attempt by 02 or 03 to perform two different actions will result in at most 
one allow decision. The case n = 3 is illustrated in Figure llObl where each of the three users is 
permitted to perform one of the three actions. More formally, we have the following result. 

Proposition 4. Given an RPPM separation of duty policy, as described above, for any user u 
the request (u, o, a) is allowed if the request is authorized by p' and ( g ', %) and no request of the 
form (it, o, a') has been previously authorized where a' 7 ^ a and a , a' £ {ai,..., a n }. The request 
is denied otherwise. 

Proof. The proof proceeds by induction on the number of evaluated requests. Consider the (base) 
case when no requests have yet been made. A request (u, o, a) where a £ {ai, ..., a n } will not 
match (af, none,pi) for any i, 1 ^ ^ n, as no decision audit edges currently exist in the system 

graph. Thus request (u, o, a) will be authorized if it is authorized by p and (g, %) (and hence will 
be authorized by p' and (g',x))- 

Now suppose the result holds for all sequences of m requests and consider the request (it, o, a) 
where a £ {ai, ..., a n }. 

• If u has previously performed a constrained action as*, 1 ^ i ^ n, then the request will 
satisfy principal-matching rule (af, none,p.;). 

Now, if ai = a, there is no authorization rule of the form (pj,o, Oj, 0) and the request will, 
therefore, be authorized if and only if it is authorized by p and (p, y). 

Conversely, if ai 7 ^ a, then a = aj, for some j 7 ^ i, and the authorization rule (j>i,o, a, 0), 
together with the DenyOverride CRS will cause the request to be denied. 

• If user u has not previously performed a constrained action then the request will not match 
any of the principal-matching rules that were added to create p'. Thus the request will 
only be authorized if it is authorized by p and (p, y). 

□ 
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Whilst we have proposed a mechanism for separation of duty employing the DenyOverride 
conflict resolution strategy, it would be equally possible to employ list-oriented policies (as de¬ 
scribed in Section 12.4.211 assuming the added constraint rules are inserted at the start of the 
principal-matching policy. 

4.3 Interest Audit Edges 

In a similar way to decision audit edges, interest audit edges record information related to 
previous requests which can be utilised to make future decisions. However, whilst the decision 
audit edges record the direct result of a previous request evaluation, interest audit edges record 
the higher level notion of “interest” associated with those requests. A subject who requests to 
perform an action on an object can be considered to be showing an interest in that object (or an 
entity which that object is related to). An authorization system may be configured to use the 
record of this interest to determine whether a future request on that, or another, object should 
be approved or denied. The primary use case for interest audit edges is the support of Chinese 
Wall policies. 

4.3.1 Chinese Wall 

The Chinese Wall principle may be used to control access to information in order to prevent any 
conflicts of interest arising. The standard use case concerns a consultancy that provides services 
to multiple clients, some of which are competitors. It is important that a consultant does not 
access documents of company c if she has previously accessed documents of a competitor of c. 

To support the Chinese Wall policy, data is classified using conflict of interest classes to 
indicate groups of competitor entities [8j. Requests to access a company’s resources within a 
conflict of interest class will only be authorized if no previous request was authorized accessing 
resources from another company in that conflict of interest class. 

Let us suppose that for a given conflict of interest class c and every user u , we have G,u,c \= 
7 ri, and for every resource o, we have G, o, c |= n 2 ■ Then for this conflict of interest class we 
have G, it, o |= 7 Ti ; 7 T 2 for every user and resource. This arrangement is depicted, conceptually, 
in Figure IllaP^I We introduce a logical entity into the system graph to represent a conflict of 
interest class and the relationship m , where an edge (c, i,m) indicates company c is a member 
of conflict of interest class i. (We assume here that membership of conflict of interest classes is 
determined when the system graph is initially populated and remains fixed through the lifetime 
of the system.) 



(a) basic layout with COICs (b) with audit edges 

Figure 11: Chinese Wall generalisation 


12 Figure 111 I does not show a system graph; it shows high-level representations of the “shape” of a system graph. 
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We now introduce interest audit edges into the system graph which are added between users 
and companies (see Figure ITTbl) . Active interest audit edges are labelled with z®, whilst blocked 
interest audit edges are labelled with z e . We, therefore, extend the set of relationships R to 
include the set {z®, z e }, thus allowing the system graph to support these new edges P^l Therefore, 
when users are authorized (or denied) access to particular data entities, authorized (or denied) 
decision audit edges will result for these requests as shown in Figure fITbl 

Given a system graph G = (V , E) such that G, u, c \= 7Ti and G, o, c f= 7T2 for all users it, 
all objects o and all companies c with membership of a given conflict-of-interest class z, the 
principal-matching rule (zq ; 7f2, none,p) ensures that every request of the form (it, o, read) is 
matched to principal p. Hence the authorization rule (p, *, read,l) authorizes every u to read 
every o. Now suppose that we wish to extend this basic policy and enforce a Chinese Wall policy, 
which requires that if a user u reads a document belonging to company c where (c, i, m) £ E 
then u must not read any document belonging to c', where c' d^_c and ( c',i,m ) £ E. Then 
we redefine the principal-matching rule to be (nq ; 712 , z® ; zfqpjlij Consider an initial request 
(it, o, read), where o is a document owned by c a member of conflict-of-interest class z. If principal 
p is matched, that is 

G, u, o 1= 7Ti ; 7 T 2 and G, u, o z® ; 7 T 2 , 

then the request is authorized (since the principal p is matched) and the following edges are 
added to G: 

• (u,c,i®); 

• (u, c',z®) for all d 7 ^ c where (c, z,m) £ E and (c',z,m) £ E; and 

• (it, o, read®). 

Consider a subsequent request (it, o', read), where o' is owned by d ^ c and d belongs to the 
same conflict-of-interest class as c. Then G, it, o' (= z® ; zr 2 and principal p is no longer matched 
and the request will be denied (assuming we deny by default). 

This is illustrated in Figure fl2l where 7Ti = w ; s and 712 = d. A member of staff iq works 
for a consultancy firm ei that acts on behalf of clients (ci, C 2 and C 3 ) and stores data about 
the commercial interests of those clients in the form of files (/ 1 , / 2 , fs, and fd). We denote 
edges of the form (it, c, z®) with a filled circle head and those of the form (zt,c, z®) with a filled 
square head. The figure illustrates the system graph before and after requests (iq, / 1 , read) and 
(iq, ./d, read) have been authorized. This results in additional edges in the system graph, notably 
(ill, C 2 , z®), which means that G, iq, |= z® ; ziq and the request (iq, / 2 , read) would be denied 
(since p would not be matched). Note that request (iq, / 3 , read) would be permitted because 
G, ui, f 3 z® ; 7T2. The audit and interest edges added through evaluation of these two further 
requests are also shown in Figure ITUbl 

Our discussion has so far considered the case where a single path of relationships exists be¬ 
tween users and companies and between objects and companies; in reality there may be multiple 
alternative paths and the basic layout can be adjusted to enable this 1^1 To support such multi- 
path scenarios, the approach described above can be generalised as follows. Let 7 Ti,..., zr n where 

13 Whilst we do not rely upon decision audit edges to enforce Chinese Wall policies they, equally, do not 
interfere with interest audit edges. Our discussion of Chinese Wall will consider an authorization system which is 
also supporting decision audit edges so as to provide a more complete picture of an extended RPPM model. 

14 If our base principal-matching rule employed a prohibited target already then we could still enforce the 
Chinese Wall policy by inserting an additional principal-matching rule of the form (i® ; 7f2, none, Pbiock) where 
the principal Pbiock is denied all actions on all objects m ■ 

15 The key components of the basic layout are the existence of a subset of system graph entities C C V (in our 
example companies) connecting users to objects, the fact that each c G C is a member of at most one conflict of 
interest classes i, and the fact that C is the range for interest audit edges. 
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n ^ 1 be paths between users and companies, and let 7 rj,..., n' m where to ^ 1 be paths between 
objects and companies. The set of principal-matching rules required to authorise users to access 
objects (through all possible combinations of these paths) is 

j(7Tj ; 7 Tj , none, p) : 1 sj * sj n, 1 < j to} . 

In order to support Chinese Wall policies, these rules are modified to 



(a) system graph fragment (b) after four requests 


Figure 12: Enforcing the Chinese Wall policy in RPPM 


5 Related Work 

Our work is motivated by the limitations of role-based access control in respect of the context 
in which authorization requests are made. A medical doctor should not be given access to all 
patients’ records simply because she is a doctor; it is only her patients’ records to which she 
requires access. We believe, as others do, that the relationships between entities within a system 
are intrinsic to the decision making process Whilst this approach has received 

considerable interest, much of the previous work has focused on applying relationship-based 
access control to online social networks. This is no doubt due to the obvious alignment between 
the relationships in the access control model and the strong focus on interpersonal relationships 
in such networks. As we have shown here, however, relationship-based access control can be 
applied to general-purpose computing systems (as well as in social networks). 

Early work in this field focused solely on social networks and considered friend and friend-of- 
a-friend relationships to determine access to resources [30], as well as trust relationships between 
users [3]. These ideas were drawn together by Carminati et al. m to create an access control 
model for social networks based on relationships. This work has more recently been built upon 
by Hu et al. m to provide joint management of access policies (once again focused on social 
networks). 

Fong et al. provided a richer policy language, based on modal logic [ana and then hybrid 
logic [2IT|. This policy language is not directly comparable to that of the RPPM model but 
there are common elements: both support defaults, relationship labels, positive and negative 
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requirements, and can encode alternation (since the RPPM model may use multiple principal¬ 
matching rules for the same principal). However, the RPPM model’s policy language supports 
unbounded path conditions, which are useful when traversing a sub-graph comprising similar 
types of elements with paths that may be arbitrarily long (as in a directory tree, for example). 
Moreover, we allow for arbitrary types of nodes in the system graph, which allows us to model 
relationships in general-purpose computing systems. 

In terms of policy specification, the work of Cheng et al. is the most similar to our own mm 
Whilst the focus of their work is again social networks, it allows for the specification of user-to- 
resource relationships other than ownership. Our RPPM model is more general still in its support 
for entities of any kind (including logical ones) and policies not focused on, but still applicable 
to, social networks. The policy language used by Cheng et al. is based on a limited form of 
regular expressions, but limits the Kleene operators to a fixed, short, depth. It is claimed that 
such restrictions are appropriate in social networks because of the “six-degrees-of-separation” 
phenomenon, which means the diameter of a social network is very small (compared to the 
number of nodes it contains). However, no such assumptions can be made for more general 
systems, such as those to which the RPPM model can be applied. We do not bound the Kleene 
plus operator and are able to support the Kleene star operator through the use of two principal¬ 
matching rules. Finally, Cheng et al. do not allow cycles in the social network, when considering 
request evaluation with respect to their policies. We see no reason why nodes should not be 
revisited and make no such restriction. 

There has been some interest in recent years in reusing, recycling or caching authorization 
decisions at policy enforcement points in order to avoid recomputing decisions [’7, 23 ESI GS] ■ 
These techniques have perceived benefit, in particular, in large-scale, distributed, systems due 
to demands for reduced latency and a resilience to intermittent communications failures. Whilst 
caching in the RPPM model does not resolve connectivity issues directly, the capability has con¬ 
siderable impact on latency. Significantly, caching edges have direct value in the RPPM model, 
allowing the computationally expensive part of the decision-making process to be bypassed. Fur¬ 
ther, a cached edge applies to multiple requests (as it considers the participants but not the 
action) and so can optimise processing at a level of abstraction above that which is commonly 
employed by other strategies. This allows for more intuitive and less specific optimisation strate¬ 
gies and algorithms, which have demonstrable value (as shown in preliminary experimental work 
by Crampton and Sellwood [TB]). Finally, whilst many authorization recycling strategies involve 
the policy enforcement point maintaining its own cache, or employing a “speculative” system m, 
caching in the RPPM model updates the system graph itself and can thus be implemented by 
very simple extensions to the basic model. 

The RPPM model’s support for auditing edges provides a natural mechanism through which 
to record past activity and thus inform future authorization requests. Brewer and Nash’s seminal 
paper on the Chinese Wall policy [8] led to considerable research into history-based access control, 
which continues today. Fong et al. m recently proposed a relationship-based model that incor¬ 
porates temporal operators, enabling the specification and enforcement of history-based policies. 
Once again, this model was developed in the context of social networks and cannot support the 
more general applications for which the RPPM model can be used (such as the Chinese Wall 
policy). 


6 Conclusion 

We have introduced the RPPM model for access control based on the concepts of relationships, 
paths and principal matching. We make use of relationships within our graph-based model to 
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make authorization decisions. By allowing the system graph to contain logical, as well as concrete 
entities, we enable contextual relationships to inform the decisions. This is further demonstrated 
by the model’s support for typed edges, thus allowing historical activities to influence the eval¬ 
uation of current requests. Through the use of these features, the RPPM model is able to easily 
accommodate our motivating examples from Section [L] 

Our model has rigorous foundations, using polices based on the concept of a path condition 
which may be viewed as a restricted form of regular expression. This, in turn, means we can 
describe the algorithm for evaluating access requests in terms of non-deterministic finite automata 
and determine its complexity. Moreover, the expressiveness of path conditions does not need to 
be artificially constrained and we can thus represent a much wider range of policies than is 
possible with other proposals in the literature. The flexibility of path conditions, comprising a 
mandated and precluded target, allows for the definition of practical and powerful authorization 
policies which are intuitive to interpret. This allows for general computing applications such 
as file-systems and other tree structures (of arbitrarily large depth) to be modelled effectively. 
Moreover, the model’s support for caching edges enables the authorization system to bypass 
the expensive principal-matching algorithm in cases where it has already been performed. The 
benefit of caching in the RPPM model is tangible and significant whilst incurring little overhead 
to implement. 

The generality and flexibility of the RPPM model makes it an ideal basis upon which further 
work can be built. Audit edges, as well as providing support for the enforcement of separation- 
of-duty and Chinese wall policies, introduce a natural route into workflow task authorization and 
stateful resources to which access changes over time. We also plan to develop an administrative 
model for the RPPM model by including administrative principals and rules for matching ad¬ 
ministrative principals to requests that modify the state of the system (such as adding nodes and 
edges to the system graph). More speculatively, we hope to consider strategies for partitioning 
the system graph into sub-graphs each having their own policies and using “hub” entities to cre¬ 
ate “bridges” between the sub-graphs. The intuition is that segmentation of the system graph 
may hold the key to more space-efficient policy representation, storage and retrieval, as well as 
more time-efficient request evaluation. 
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